Distributed computer environments, such as computer networks, provide significant advantages to multiple computer clients or users. In particular, distributed environments allow multiple clients to actually share many different computer resources including both hardware and software resources. Sharing software-related resources provides many known benefits, such as the fact that only one such resource needs to be created, updated and maintained.
The Internet is one particular example of a distributed environment that provides access to a considerable number of software resources, which are available to practically any client computer system having Internet capabilities. One portion of the Internet is known as the World Wide Web which is a generally a system of Internet servers that house software related resources that are formatted in a particular manner, such as with HTML (HyperText Markup Language). The protocol for accessing these particular resources is known as the HyperText Transfer Protocol or HTTP. It should be noted however that not all Internet servers are part of the World Wide Web.
With recent advances, clients may effectively author resources on a server system from client systems over distributed networks, including the Internet. For instance, the WebDAV protocol or standard, which stands for the World Wide Web Distributed Authoring and Versioning standard, referred to herein as simply “DAV,” provides a set of headers and methods which extend HTTP to provide capabilities for managing properties, namespace and other items from a client system in order to allow client computer systems to access server-side resources for the purpose of editing those resources. Proposed Standard RFC 2518, which is a document written by the IETF and approved by the IESG, published February 1999, describes DAV in more detail.
As part of the DAV standard, server computer systems provide various services in managing the various access requests made by clients. One particular service relates to controlling when a resource is available for use by a client. That is, DAV provides methods that allow a client to lock a resource when using that resource so that subsequent users may not access that resource during that time. This locking scheme helps prevent the “lost update” problem associated with two or more users modifying a resource simultaneously such that editions are inadvertently lost. Additionally, the locking scheme provides an ability to lock two resources that may be needed to perform a file-management type function. For example, assuming a resource exists in one folder, yet the owner wants to move the resource into another folder, i.e., the destination folder. In such a case the client needs to lock both the resource and the destination folder. Locking both resources allows for the operation to proceed without conflicts.
Although the locks are helpful in preventing the lost update problem, the present locking system implemented in DAV is unsatisfactory with respect to the allocation of these locks. For instance, a DAV lock only covers, at most, one resource tree. That is, the lock request itself typically includes a uniform resource identifier (“URI”) and a depth. The depth indicates the number of levels of sub-elements or children of the resource identified by the URI to be locked. Unfortunately, if the client system needs to lock multiple URIs that are not in a parent child relationship, multiple lock requests are required. In return, the client system receives multiple lock tokens or cookies representing the locks on the various resources. Since many operations typically involve several different and unrelated resources, the request, receipt and management of the multiple locks increases the overhead involved.
Moreover, requesting multiple locks is not a satisfactory solution since some locks may be granted while others are not which negatively affects the atomicity of a requested operation. An atomic operation or the atomicity of an operation, relates to an operation that must be performed entirely or not at all. Since lock requests are typically associated with a particular access or command request, atomicity is typically required. Therefore, the partial granting of a selective few of the locks is not acceptable.
Additionally, if two or more separate client processes attempt to lock the same resources, a potential deadlock situation may occur, where each locks one of the resources but prevents the other(s) from locking all the resources. A deadlock situation precludes lock success for each of the processes. One solution to this problem involves a server-side utility that monitors lock requests and attempts to “remember” whether a lock request has been granted to a client process that is now requesting a subsequent resource. Recognizing that a client process is requesting a subsequent resource provides the server the ability to anticipate potential deadlock situations before they occur. Unfortunately, a significant amount of overhead is required to store information related to all previously granted lock requests, and the client that requested the lock.
It is with respect to these and other considerations that the present invention has been made.